The Open Mobile Alliance Device Management (OMA DM) Work Group has developed the standard specifications for device management. As defined in the specifications, the third party (for example, mobile carrier, service provider, or information management department from a partner) uses a device management (DM) server to manage and set the environment and configuration information of terminal devices such as mobile phones and functional objects in terminal devices on a radio network. This helps solve various problems in operating the network devices. The DM server and terminal devices can be integrated to form a DM system in which the DM server manages and configures the terminal devices in the over the air (OTA) manner, such as installation and upgrading of software and firmware. This helps deliver customized services and improve user experience.
As shown in FIG. 1, in the DM system, a DM agent in a terminal device parses and runs management commands sent by the DM server. A DM management tree stored in a terminal device can be regarded as an interface through which the DM server manages the terminal device based on a DM protocol. The DM management tree includes basic management objects (MOs). To control the MO of the terminal device, the DM server sends operating commands to operate the MO of the DM management tree. The operating commands include “Get”, “Replace”, “Exec (execute)”, “Copy”, “Delete”, and so on.
The DM management tree of the terminal device also includes unnamed nodes which serve as placeholders. After being instantiated by the DM server or terminal device, the unnamed nodes are named. These nodes are called x nodes.
As shown in FIG. 2, the DM protocol has defined a standard DevInfo (device information) MO for storing basic information about the terminal device in the DM management tree. For example, “DevId” denotes a device identification (ID), “Man” denotes a manufacturer, “Ext” denotes extension, and “Bearer” denotes a bearer network, where the Ext and Bearer respectively includes an unnamed node x and an unnamed node y referred to as x nodes. When the terminal device is in operation, nodes x and y may be instantiated and named. For example, node y may be named “CDMA”. In FIG. 2, the symbol “*” indicates that the node can be used many times or, alternatively, is not used at all. Additionally, the symbol may include “+” to indicate that the node can be used one e or many times. Therefore, node y can be instantiated multiple times. For example, node y can be instantiated and named “GSM” after being named CDMA, and then Bearer has two nodes, namely, CDMA and GSM.
As shown in FIG. 3, in the instantiated DevInfo MO, the x node is instantiated to three nodes with different names, namely, “VendorSpecial1”, “VendorSpecial2”, and “VendorSpecial3”.
The x nodes may fall into two types: internal node or leaf node. The internal node indicates that the node has sub-nodes, and the leaf node indicates that the node cannot have a sub-node. For example, the x node in the Push MO in FIG. 4 is an internal node. The x node in FIG. 2 is a leaf node. Additionally, nodes in the management tree can also fall into two types: permanent node or dynamic node. The permanent node indicates that the node is created before the terminal device leaves the factory and cannot be deleted. The dynamic node indicates that the node can be created and deleted when the terminal device is in service. The x nodes are dynamic nodes.
Additionally, according to the DM protocol, both named nodes and x nodes include their own Framework property, which is defined by the device description framework (DDF). As a file used by equipment vendors for describing the structure of the management tree inside the terminal device, the DDF includes information about relation between nodes, node property, and so on. The Framework property of a node includes AccessType, DefaultValue, Occurrence, and so on to identify the features of a node.
In implementing the present disclosure, the inventor has identified problems with regards to the conventional art. The conventional art does not specify rules for naming the x nodes when the MO instance is being created in the management tree of the terminal device. One reason may be that when the x node is being created by the server, this node may be named by meaningless characters, such as pure numbers. Therefore, another server may fail to obtain the node content when querying this node. As shown in FIG. 4, for example, when querying the TrustedSMSC node, the server can obtain the quantity and names of instances of its sub-node. If the instances are named by meaningless characters, however, the server will fail to obtain the meaning of the instances and the content of the downstream of the instances. Only after the server has queried the sub-nodes can it define this node (for example, the server can infer the content of this node according to its sub-nodes). This causes multiple interactions between the terminal device and the server, high seizure ratio of resources, and long processing duration.